iT邦幫忙

2026 iThome 鐵人賽

DAY 3
0

今日重點

今天的目標就是跟大家分享說明我當時發展內部 Skill 的過程。

過程

題目發想其實蠻明確,我就是要發展一套 Code Review 的 Skill。

做這件事的目的是因為每套 AI Agent (Claude Code, Codex, Antigravity)其實與生俱來都有能力進行 Code Review 但是我能感覺得出來那個能力過於發散,然後報告的結果雖然對,但你就知道有點缺了什麼的感覺。

我會這樣比喻:各個 LLM 都是能力很強的員工,若我們沒有給予合適且足夠的引導,他肯定能做事,但是可能就會跟這個組織長久以來的習慣脫節。所以組織會透過 SOP、一些規範等等的來對齊員工的流程,而 Skill 就是給 AI Agent 的那份 SOP,讓你的 AI Agent 可以更貼近我所預期、所期望的成果,符合我的習慣、我的思維甚至是我的價值觀。

萃取一個我

如同標題講的,我要怎麼開始?我的思維怎麼來的?我難道要從零開始寫這份 Skill?

素材

由於我不覺得我能從零自己建構出最終的 Skill 所以我轉向調閱既有的資料,請 AI 自己來彙整相關的素材。我動用了以下資源:

  • 過去一兩年來我在別人的 MR 上面所給的回覆、留的言,裡面有我識別出的問題,並且針對該面向的問題提供建議,這個就可以傳遞出我自己對於一個問題是如何拆解、判定它的嚴重程度、該使用怎麼樣的手法解決此問題
  • 我為內部同仁寫過相關的教學網頁、文件
  • 我在通訊軟體上面回應問題的紀錄
  • 內部由我主導的教學、上課錄音逐字稿

以上這些我當時就是也都提供給 AI Agent 請它進行彙整與分析。

我要它做的轉換

素材丟過去的時候,我沒有叫它「幫我寫一份 Code Review 規範」。那樣要來的會是一份網路上本來就找得到的東西。

我的要求分兩層。第一層是先讀懂人:

  • 我是怎麼想事情的
  • 我怎麼分析一個問題
  • 我怎麼回覆別人
  • 我怎麼做分級
  • 我怎麼調查一個事件
  • 我的價值觀是什麼

讀完這六件事,才是第二層:以工程的角度,把它們劃分到不同的類別裡。

第二層才是整件事的關鍵。人的東西是混在一起的:我在一則 MR comment 裡,可能同時做了判定、給了理由、挑了語氣,還順手教了一件事。工程上要用,就得把它們拆開,因為載入的時機不一樣:判定規則每一次審查都要讀,語氣只有在寫報告那一刻要讀,而教學的部分多半根本不該進 skill。

按「什麼時候才需要讀到它」來切,切出來的東西才有辦法按需載入:入口只放路由,細節留在原地,走到哪一步才讀那一份。這個作法其實就是所謂的 progressive disclosure(漸進式揭露)

最後長出來的分類大致是這樣:

人的那一面 變成 skill 裡的什麼
我怎麼分析問題、怎麼調查事件 審查流程本身:先做什麼、什麼時候才准下判斷
我怎麼做分級 各個面向的規則,以及每一條的嚴重度判準
我怎麼回覆別人 報告的語氣規範,以及作者不同意時怎麼處理
我的價值觀 那些「我們決定接受這個風險」、「這件事在我們這裡要升級」的條款
我怎麼想事情 判斷這個 MR 該不該做、該不該在這個時候做

同一批素材,如果只叫它「整理成規範」,出來的是一份很長的清單。要求它先讀人、再分類,出來的才是一組各自有職責的檔案。

呈現方式

以前接觸的資安相關的報告以及相關的規範通常是分成三個等級,所以當時的我也希望 Review 報告在呈現上也能是分成三個等級:

  • Critical:表示有立即危害,必須排除才可決定是否 合併 到主分支
  • Suggestion:傾向需要調整,但未調整仍可 合併 到主分支
  • Nit:其他建議,由作者自己決定是否需要相應的調整

有了先前的素材之後,LLM 應可以透過案例理解我們是怎麼判斷輕重緩急的,由於我們是醫療環境:

  • 操作原子性在一般多數情境會是 Suggestion 但我就想將其標示為 Critical 等級
  • 每個項目會延伸去想是否對於病人安全、病人資料隱私造成多大的影響
  • 也有一些議題,AI 預設會判得很重,但實務上是風險管理的取捨題
  • ... 相信大家在各自的領域也一定有自己 心中的一把尺 而這也是既有很多 Code Review 服務 / Skills 能用,但是你就是覺得它缺了些什麼的原因

後記

我一開始整個 Skill 是用繁體中文建立、調整的,但後來 Skill 內容日益增長,後來看到這篇文章:

  • 轉貼與討論(Generative AI 技術交流中心,我在這裡看到的)
  • 原始貼文(2026-04-28),下方圖片也源自此貼文:

文章指出 Claude 的 tokenizer 處理中文約為英文 1.65 倍用量;我自己實測將 Skill 全文英文化後從 ~40K 降到 ~29K tokens(省 ~28%)。

差異可能來自英文版不是逐字翻譯,是重寫。

兩個數字都要看時間。 那張表是 2026 年 4 月底量的,我自己那次英文化實測是同年 5-6 月,兩次用的都是當時的 tokenizer,而 Claude 後來換過一次,同一段文字被切出來的 token 數可能就不一樣了。所以 1.65 這個倍數說明的是「中文比較貴」這個方向,不拿它去推算現在的帳單。

另外那張表還有一格值得看:中文那一列的跨家平均只有 1.02 倍,Anthropic 的 1.65 是明顯的離群值。也就是「中文吃 token」這件事對 Claude 特別成立,對其他家幾乎不成立。這也是為什麼英文化這件事在我這裡值得做。

最後這一套完整的 skill,正式名稱叫 nathan-code-review(Nathan 是我的英文名,後面文章會看到它的縮寫 ncr- 出現在各種地方);

不過由於我姓傅,中文我都叫他「傅製人」😁

接下來我們就會走向建立一套適合於你的流程情境現實的 Code Review Skill 也會向大家分享我目前所使用的大致架構。


上一篇
Day 2|為什麼從 Code Review 開始?
下一篇
Day 4|第一份 Skill:動工規劃
系列文
AI 的駕馭之道:一個 AI Code Reviewer 的養成、評測與邊界實錄7
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言